Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/openhuman/tools/impl/computer/keyboard.rs`:
- Around line 254-271: The current spawn_blocking block using Enigo::new and
iterating over keys stops on the first Press/Release error and can leave
modifier keys held; change it to track which keys were successfully pressed
(e.g., a Vec pressed_keys) as you iterate in the Press loop, and if a Press
fails immediately jump to a cleanup section that attempts to Release all
pressed_keys in reverse order (ignoring or logging any Release errors so cleanup
is best-effort). Also wrap the normal end-of-block Release loop in the same
best-effort pattern (release each key and log but do not return early on Release
errors). Use the existing symbols Enigo, keys, HOTKEY_INTER_KEY_DELAY and the
spawn_blocking closure to locate where to implement the pressed_keys tracking
and the guaranteed reverse-order release cleanup.
- Around line 94-97: The hotkey handler currently drops non-string entries and
doesn't enforce modifier-first plus one final non-modifier pattern; update the
hotkey validation to (1) reject any non-string entries up-front, (2) map strings
to Key values and fail if any mapping fails, (3) use is_modifier(&Key) to
require at least one modifier and exactly one trailing non-modifier with all
modifiers preceding it (e.g., modifiers... + final non-modifier), and (4) return
an error/false without sending any key events for malformed arrays. Locate the
hotkey parsing/firing logic near the code that currently filters or iterates
over the array (the block around where strings are converted to Key and keys are
fired) and add this validation before any calls that press/release keys so
malformed inputs like ["Ctrl", 1], ["Ctrl"], or ["a", "Ctrl"] are rejected.

In `@src/openhuman/tools/impl/computer/mouse.rs`:
- Around line 225-239: The drag closure in tokio::task::spawn_blocking calls
enigo.button(Direction::Press) then may return early on subsequent errors
leaving the button pressed; refactor so the press is followed by a best-effort
cleanup that always calls enigo.button(button, Direction::Release) on error or
panic. Concretely: after Enigo::new and the initial move_mouse and
button(...Press) call, perform the remaining operations inside a fallible block
(e.g., let result = (|| -> Result<_, _> { ... })();), and if result.is_err() or
a panic is caught, call enigo.button(button, Direction::Release) (ignoring its
errors) before propagating the original error; alternatively implement a small
RAII/guard type tied to the enigo instance that calls Release in Drop unless
explicitly disarmed. Ensure you reference the existing enigo variable, the
button press/release calls, and the move_mouse invocations when applying the
fix.
- Around line 28-34: parse_button currently returns Button and maps any unknown
string to Button::Left; change its signature to return Result<Button,
anyhow::Error> (or your crate's common error type) and return Err (e.g.,
anyhow::bail!("invalid mouse button: {}", value)) for unknown or non-string
"button" values instead of defaulting to Left, and update all call sites to use
parse_button(&args)? so the error propagates (references: parse_button and the
Button enum).
- Around line 253-255: The "scroll" match arm currently narrows scroll_x and
scroll_y using `as i32`, which can silently wrap out-of-range i64 values; update
the handling for `scroll_x` and `scroll_y` to validate the i64 range before
conversion (e.g., use i32::try_from(...) and handle the Err case or clamp values
to i32::MIN..=i32::MAX) and return or propagate an error when inputs are
invalid; locate the variables `scroll_x` and `scroll_y` in the "scroll" arm of
the match in mouse.rs and replace the `as i32` narrowing with a range-safe
conversion and proper error handling.

---

Nitpick comments:
In `@src/openhuman/tools/impl/computer/keyboard.rs`:
- Around line 145-150: Add development-oriented trace/debug logs for the
blocked/failure branches in keyboard handling: when self.security.can_act()
returns false and when self.security.record_action() returns false, log a
structured message (including agent id/session/state if available), the reason
("autonomy read-only" or "rate limit exceeded") and early-exit via
ToolResult::error; similarly add trace/debug entries around validation failures,
enigo calls, and their error branches (the call sites referenced around lines
157-161, 182-196, 210-224, 254-283) so each entry/exit, branch decision,
external enigo invocation, and error path emits context-rich logs. Use the
existing logging/tracing facility used in the crate (e.g., trace!/debug!/warn!
with key fields) and ensure logs include unique identifiers so blocked actions
are observable in traces.

In `@src/openhuman/tools/ops.rs`:
- Around line 157-162: Add a small unit/regression test that asserts the
native-input gate behavior around root_config.computer_control: verify that when
computer_control.enabled is false the resulting tools registry/vector does NOT
contain MouseTool or KeyboardTool, and when enabled is true the registry DOES
contain MouseTool and KeyboardTool; locate the code that constructs the tools
vector (the block that checks root_config.computer_control.enabled and pushes
MouseTool::new and KeyboardTool::new) and write tests that toggle that config,
call the tool-construction function, and assert presence/absence of those
specific types by inspecting the tools vector or registry.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/openhuman/tools/impl/computer/mouse.rs`:
- Around line 91-110: Update the JSON schema descriptions for the "x" and "y"
properties to include that they are required for the "drag" action as well as
move/click/double_click; locate the schema entries for "x" and "y" (keys "x",
"y" in the mouse action schema) and change their description text to mention
"Required for move, click, double_click, and drag" so runtime expectations for
the "drag" action (which uses x/y as end coordinates) match the schema.

---

Nitpick comments:
In `@src/openhuman/tools/impl/computer/mouse.rs`:
- Around line 155-161: Change the success-path tracing calls from info! to
debug! for the mouse tool so routine, development-oriented diagnostics are
emitted at debug level; specifically replace the info! invocation that logs
tool="mouse", action="move", x/x, y/y and the other similar info! blocks (the
ones around the reported ranges 179-183, 206-210, 265-270, 316-322) with debug!
while keeping the same structured fields and message text, and ensure the
tracing/log crate is imported or available for debug! macros where these changes
are made.